1. Field of the Invention
This invention pertains in general to computer software update deployment, and more specifically to techniques for controlled release of software updates to random subsets of seed users over time.
2. Description of the Related Art
Deploying a software update to a large number of users at a time can pose numerous problems since such updates sometimes introduce software bugs or cause other problems when released to the public. Software companies have attempted to deal with this problem by limiting the initial release of a new software update to only a subset of all possible users. If a software update is released to only 10,000 machines in a first round of release rather than to the entire pool of millions of users, it is much easier to deal with any problems or bugs introduced by the software. The users who are affected by the problem are much fewer and more manageable in this type of limited initial release.
There are a number of different ways in which this type of limited software update deployment has been performed. One method involves limiting the initial release only to users in a particular target country or some other defined subset of users. For example, all users in Denmark for a particular software application that is being updated will receive the update first and can report any problems with the software before it is released to the general public. However, this manual release method has caused problems in the past when, for example, a particular bug only manifested itself in the target country and nowhere else. Thus, in those instances, the testing of the product by the seed users in the target country was not representative of the entire population of users of the software application to whom the update would ultimately be deployed.
Another method for limiting update release includes the timed posting and removal of updates. For example, the software update can be made available to the general public at 2 a.m. for a couple of hours, and then the update is removed. The goal of this method is to permit a subset of users to have a chance to download the update during this two-hour window, and those users can report problems with the software update before it is released more generally to the public. The company distributing the software can monitor for bug reports and reports of system crashes to determine whether the update is ready to be provided to a broader group of users. This manual release method, however, is still not very useful because there are no statistics tied into the update release, and there is no way to know who the seed users are or whether the coverage of the seed user base is adequate for testing the software before a much wider release.
None of the above manual methods of release provide a sufficient amount of control over the software update deployment. However, control is particularly important in situations where software updates have to be released on a very short time frame, since the patch may be needed to resolve a current issue that users are facing with the software. If the software update has to be released within a week, there is very little time to run an actual beta test cycle for the update. For example, the posting and removal of software at 2 a.m. may have to be repeated numerous times over a few days to get enough downloads to form a significant enough seed user base. However, for a critical software update for which time is of the essence, there may not be time to develop a representative base and the product may be released to the public before being properly tested.
Therefore, there is a need in the art for a method that allows a more uniform mechanism of systematically sending out software updates to a defined and random proportion of seed users before the mass distribution of the update, allowing software updates to be controlled to a much more granular level.